home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000054_owner-urn-ietf _Wed Nov 6 05:45:18 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  5KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA07466 for urn-ietf-out; Wed, 6 Nov 1996 05:45:18 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA07459 for <urn-ietf@services.bunyip.com>; Wed, 6 Nov 1996 05:45:16 -0500
  3. Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA09116  (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 05:45:11 -0500
  5. Received: from ifi.unizh.ch by josef.ifi.unizh.ch 
  6.           id <00576-0@josef.ifi.unizh.ch>; Wed, 6 Nov 1996 11:44:06 +0100
  7. Subject: Re: [URN] I18N does not belong in URNs
  8. To: moore@cs.utk.edu
  9. Date: Wed, 6 Nov 1996 11:44:05 +0100 (MET)
  10. Cc: tallen@fsc.fujitsu.com, urn-ietf@bunyip.com
  11. In-Reply-To: <199611060233.VAA20653@ig.cs.utk.edu> from "Keith Moore" at Nov 5, 96 09:32:59 pm
  12. Mime-Version: 1.0
  13. Content-Type: text/plain; charset=US-ASCII
  14. Content-Transfer-Encoding: 7bit
  15. Content-Length: 3278
  16. From: Martin J Duerst <mduerst@ifi.unizh.ch>
  17. Message-Id: <"josef.ifi..460:06.10.96.10.44.08"@ifi.unizh.ch>
  18. Sender: owner-urn-ietf@services.bunyip.com
  19. Precedence: bulk
  20. Reply-To: Martin J Duerst <mduerst@ifi.unizh.ch>
  21. Errors-To: owner-urn-ietf@bunyip.com
  22.  
  23. Keith Moore answers Terry Allen:
  24.  
  25. >> Keith Moore writes:
  26.  
  27. >That's not true.  People regularly transcribe telephone numbers, 
  28. >email addresses, ISBNs, URLs, credit card numbers, etc. with 
  29. >sufficient accuracy for their purposes.  But ask people to 
  30. >transcribe identifiers in (say) Klingon, or to type them in 
  31. >on a keyboard not designed for such, and you'll get much lower 
  32. >accuracy.
  33.  
  34. Most telephone numbers of companies are meaningful. Most
  35. email addresses are meaningful. Many URLs are meaningful.
  36. Transcribability is aided by meaninfulness; there is a smaller
  37. chance to make a mistake if one of these things is meaninful
  38. than without meaningfulness.
  39.  
  40. And Klingon is a VERY bad example. Nobody speaks Klingon.
  41. Nobody grew up with Klingon. Nobody learned Klingon in
  42. school as we learn the Latin script, and others learn
  43. their traditional scripts. And Klingon isn't even in
  44. Unicode. Klingon is a fancy of some SF enthusiasts,
  45. and not a script used by millions every day to express
  46. and exchange their thoughts and feelings.
  47.  
  48. >> Your
  49. >> last point would have merit were it not that we absolutely must
  50. >> be able to grandfather in existing name spaces.
  51. >
  52. >Yes, we must be able to grandfather existing name spaces *that serve
  53. >similar purposes to URNs*.  ISBNs qualify.  Handles qualify.
  54. >Usenet message-ids qualify.  But URNs don't have to handle existing
  55. >name spaces that don't have the characteristics that URNs have.
  56. >Offhand, I don't know of any name spaces that have such characteristics,
  57. >that attempt to be human friendly.
  58.  
  59. ISBNs don't qualify. They are not persistent. And the fact that you
  60. don't know about any such namespaces doesn't guarantee that there
  61. are no such namespaces.
  62. About 30 years ago, some people said "I don't know of anybody
  63. that would want to use anything else than English on computers".
  64. And then they went on to design protocols :-(.
  65.  
  66.  
  67. >> We should be building the big tent that everyone can live under,
  68. >> not trying to close out name spaces we don't like.  
  69. >
  70. >Yes, and we should also be restricting the problem to something that has 
  71. >a hope of a reasonable solution.  They're not mutually exclusive, but 
  72. >over-reliance on the "one big tent" theory has caused the failure of 
  73. >many protocols.
  74. >
  75. >(Please note that assuming we can define I18N'ed URLs -- and there is 
  76. >certainly a better case to be made for these then I18N'ed URNs -- I 
  77. >would have no problem with this group defining resolution protocols that 
  78. >can be used with them.  It's just that I18N isn't appropriate for the 
  79. >URN name-space.  And I18N'ed URLs aren't in scope for this group.)
  80.  
  81. When I participated in several attempts and discussions to
  82. internationalize URLs, I was told by several people that have
  83. also shown up on this list that for URLs, i18n would be difficult,
  84. but that it would be solved for URNs.
  85. I definitely hate to see i18n just being moved around and delayed
  86. by some people. With UTF-8 in URNs, we have made great progress.
  87. Some protocols (notably FTP) are also going in the direction of
  88. UTF-8. Ideally, we will have a uniform solution for both URLs
  89. and URNs, based on UTF-8. For URNs, it will be by design, for
  90. URLs, it will be more by retrofitting, because according to
  91. the URL syntax document, the individual schemes have full
  92. autonomy.
  93.  
  94. Regards,    Martin.